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MULTIMEDIA COMMTT NICATIONS OVERPOWRR T.TMPJg 

CROSS-REPERENCE TO RELATED APPLICATIONS 
This application claims flia benefit of U.S. Provisional Patent AppKcation No. 
60/234,016, filed September 20, 2000, which is incorporated herein by referaice. 

FIELD OF THE INVENTION 

The present invention relates generaUy to data commtmications, and specifically to 
video and voice commtmications over electric power lines. 

BACKGROUND OF THE INVENTION 
Data communications using residential power lines are known in the ait An advantage 
of using the lines is that only peripheral infiiastructure needs to be added to the existing power 
lines in order to transmit and recwve the data communications. With appropriate modems, 
power lines can be used to cany all the types of data traffic that are crarraitly carried on local 
area networics (LANs), wide area networks (WANs) and internets, including real-time voice 
and video. Among the disadvantages of using power lines are high attenuation and the high 
level of interference on the lines, such as voltage spikes and Gaussian noise. These 
characteristics impose limitations on the available bandwidth and reHabffity of power line 
communications, which should be taken into account in the data swvices that are offbred over 
power line networks. 

Ja packet networits such as the Memet, the Real-time Transport Protocol (RTP) is 
commonly used to cany real-time multimedia tra£6c. such as video and voice. This protocol is 
described by Shulzrinne et al., in «*RTP: A Transport Protocol for Real-Time AppUcations," 
published by the Network Working Group of the Internet Engineering Task Force (IETF) L 
Request for Comments (RFC) 1889 (1996), which is incorporated herein by reference. RFC 
1889 specifies a format for RTP packets that includes a 12-byte RTP header and a 20.byte 
payload. which are earned together as the payload of a User Datagram ProtocoMhtemet 
Protocol (UDP/IP) data packet. The RTP header includes a sequence' nmnber and time stamp, 
which increase by steps flom one packet to the next in a RTP stream, along with a fixed 
synchronization source identifier (SSRQ field. Most of the other fields and flags in the RTP 
header change rarely, if at aU, in the course of a RTP session. RTP is connectionless, like 
UDP, in the sense tiiat RTP packets are sfeamed continuously fiom the source to the 
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d««ntf on. mth provision for v-i&ing *e p«M«ts bav. i«*=d fl^ix d«ttaa«on 
intact. 

The Mgh ovediead of RTP packets is a cause for concern when multimedia traffic is to 
be earned over low-bandwidflx networks. The RTP. UDP and IP headers of a single packet 

5 add up to 44 bytes (compared to the 20.bytepayload). Tlie data Unk header (such as Ethernet) 
and additional signaling used for telephony ^Ucations. can easily add another 40 bytes, 
leaving only 20% of the chamiel bandwidth for the actual data. Jn response to this concern. 
Casner et al. suggest a method for KTP header compression on a link-by-link basis inlETF 
RFC 2508. entitled "Compressing IP/UDP/RTP Headars for Low^peed Serial Links" (1999). 

10 which is incorporated herein by reference. This method takes advantage of the fact that most 
of the fields in the IP, UDP and RTP headers do not change at all during the RTP session, or 
change by an increment that is generally constant. On this basis, the IP/UDP/RTT header in 
most of the packets is compressed down to two bytes, or four bytes when UDP checksums are 
included. 

SUMMARY OF THE INVENTION 
It is an object of some aspects of the present invention to provide methods and 
apparatus for multimedia communications overpower line communication (PLC) networks. 

It is a further object of some aspects of the present invention to provide methods and 
apparatus for efficient, reliable Voice over IP (VoIP) communications using PLC networks. 
20 In preferred embodim«its of the present invmtion. a communications system 

conq)rises a phiraKty of data transceivers coupled to a network of power lines, preferably 
supplying mains voltage. Typically, the transcdvers include a concentrator, which connects 
the power line network to a data communication network trunk, and power line modems in 
subscriber premises, which link subscriber equipment in the pranises to the concaittator via 
25 the power lines. The power line modems preferably include both computer data ports, to 
which a user may comiect a computer for serial or parallel data transfer, and telephone ports, to 
which the user may connect a conventional telephone handset. The concentrator is connected 
via the data communication trunk to a telephony server system, which preferably includes a 
gateway to a pubUc switched telephone network (PSTN). Users can thus send and receive 
30 telephone calls over the power lines by communicating through the concentrator with the 
telephony server, using either their telephone handsets or telephony appUcations on flieir 
computers. 
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The transceivers monitor the traffic that they are conveying in order to detect streams 
of voice or video traffic, preferably by detecting RTP packets. When either the concentrator or 
one of the subscriber modems detects such a stream, it signals the transceiver at the other end 
of the link to establish a RTP connection for carrying the traffic. The comiection is assigned a 
5 short (preferably one byte) connection identifier. The connection context, comprising the 
RTP, UDP and IP parameters that do not vary from packet to packet in the stream, is stored at 
both ends of the link, indexed by the connection identifier. Subsequently, for the duration of 
the connection, the sending transceiver removes the IP/UDP/RTP packet headera and, as long 
as the header parameters have not changed, substitutes a brief header containing the 
10 connection identifier and a sequence number for detecting lost packets. PeriodicaUy, the 
receiving transceiver returns an acknowledgment packet to the sender, indicating the sequence 
number of the last packet that was received intact, and informing the sender of any lost or 
coniq>ted packets. la this way, the narrow bandwidth of the PLC network is used efficiently, 
by reducing substantiaUy the oveihead of voice and video streams. At the same tune, the 
15 reliabiUty of voice and video communications is enhanced by adding an acknowledgment 
mechanism that is absent in the connectionless protocols usually used for real-time 
communications. 

There is therefore provided, in accordance with a preferred embodiment of the present 
invention, a mefiiod for communication, including: 

estabUshing a data link between firat and second transceivera over an electric power 
line; 

receiving a sequence of data packets for transmission over the data link, the sequence 
belonging to a session of a connectionless real-time networic protocol; 

responsive to a first packet in the sequence, estabUshing a reUable connection channel 
25 for the session over the data link between the first and second transceivers; and 

transmitting the packets in the sequence fixan the first to the second transceiver over 
the reliable connection channel. 

TypicaUy, the packets include header information, and transmitting the packets 
includes compressing the header information in the packets transmitted using the channel fiom 
the first to the second transceiver. Preferably, estabUshing the leUable comiection channel 
includes storing context information with respect to the session at the first and second 
transceivas, and compressing the header mformation mcludes compressmg the header 
infi>nnation using the stored context information. Further preferably, storing the context 
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information includes conveying the contort infonnation to the second transceiver along with a 
chamKi identifier in the first packet in the sequence, and compressmg the header infonnation 
includes inserting the channel identifier in the packets in the sequence foUowing the first 
packet as a reference to the context information. Most preferably, the mefliod includes 
reconstructing the conq,ressed header information at tiie second transceiver using the stored 
context information referenced by tiie chamiel identifier. Additionally or alternatively, 
compressing the header information inchides detecting changes in tiie header infomiahon m 
successive packets in tiie sequence, and encoding tiie changes. 

Preferably, tiie metiiod includes sending an acknowledgment fiom tiie second 
transceiver to tiie first transceiver responsive to at least some of tiie packets in tiie sequence 
transmitted by tiie first transceiver, tiiereby maintaining tiie reUable connection channel. 
Further preferably. estabUshing tiie reUable comiection channel inchides determining an 
acknowledgment interval tiiat includes a given number of tiie packets, and sending tiie 
acknowledgment includes sending tiie acknowledgment every time tiie given number of 
packets has been received at tiie second transceiver. Most preferably, transmitting tiie packets 
includes adding an error detection code at tiie first transceiver to one of tiie packets in tiie 
acknowledgment mterval. and sending tiie acknowledgment includes checking ttie error 
detection code at tiie second transceiver, and indicating a result of tiie checking in tiie positive 
or negative acknowledgment returned by tiie second transceiver. 

Additionally or alternatively, transmitting tiie packets includes adding a channel 
sequence number to each of tiie packets, and sending tiie acknowledgment includes sending an 
indication ficom tiie second transceiver to tiie first transceiver when tiie channel sequence 
number of tiie packets recdved at flie second tianscdver deviates from a consecutive order. 

Furflier additionally or alternatively. estabUshing tiie reUable connection channel 
includes sending a request fiom tiie first transceiver to tiie second transcdver to aUocate a 
resource for tiie channel, and sending flie acknowledgment indudes indicating to tiie first 
transceiver in a negative acknowledgment fliat tiie second transcdver does not have tiie 
resource available to opaa the charmel. 

In a preferred embodiment, flie first and second tianscdvers include a subscriber 
transceiver in a subscriber premises and a concentiator, and wherein tiie electric power line is a 
part of a mains voltage power Une networic to which flie subscriber tiianscdver and flie 
concentrator are connected. Typically, tiie subscriber transceiver is one of aphiraUty of such 
transceivers in multiple, respective subscriber premises connected to tiie power Une network, 
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and the concentrator is coupled to link the pluraKty of the transceivers to a packet 
communication trunk. Preferably, receiving the sequence of the data packets includes 
receiving a real-time data flow to be conveyed between the subscriber premises and a network 
server via the packet communication trunk. Most prefaably, receiving the real-time data flow 
5 includesreceivingtelephoitydata,andflienetworksen^includesatelephonygatewa^^ 

is coupled to a pubUc switched telq)hone network (PSTN). Jn a further preferred embodiment, 
receiving tiie telephony data inchides receiving data associated with a telq)hone call placed 
fiom one of the multiple subscriber premises connected to flie power line network to another 
of the multiple subscriber premises, and flie telephorry gateway is farther configured to serve 
10 as a virtual exchange, so as to convey tiie telephony data fiom the one of the subscriber 
premises to the other witiiout sending tiie data flurou^ the PSTN. 

In anotiier preferred embodiment, receiving the sequence of tiie data packets includes 
receiving real-time multimedia data, preferably video data and/or voice data. Most preferably, 
recdving tiie voice data includes coupling a telephone handset to one of the transceivers, and 
15 conveying tiie voice data as an analog audio signal between tiie one of tiie transceivers and tiie 
telqihone handset Alternatively, receiving the voice data includes coupling a personal 
computer to one of flie transceivers, and conveying tiie data packets between tiie one of tiie 
transceivers and a voice application on tiie personal computer. 

Preferably, receiving tiie sequence of tiie data packets includes receiving tiie packets in 
20 accordance witii a Real-time Transfer Protocol (RTP). 

There is also provided, in accordance witii a preferred embodiment of flie present 
invention, communication apparatus, including a first data transceiver, which is configured to 
establish a data link wifli a second data transceiver over an electric power line, such tiiat upon 
receiving a sequence of data packets for transmission over tiie data link, tiie sequaice 
b elonging to a session of a comiectionless real-time network protocol, flie first data transceiver 
is adqjted. responsive to a first packet in tiie sequence, to establish a rehable comiection 
chamiel for tiie session over tiie data link wifli flie second transceiver and to transmit tiie 
packets in flie sequence to flie second ti^cdver over flie reUable connection channel. 

In a preferred embodiment, flie sequence of flie data packets includes real-time 
multimedia data, including voice data, and flie first tiansceiver includes a telephone adapter, 
which is configured to exchange tiie voice data in flie form of analog audio signals to and from 
a telq,hone handset. Alternatively or additionaUy. tiie first transceiver includes a computer 
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conmnmcaticm port, which is configured to exchange the voice data in the form of voice 
packets to and from a voice appUcaiion on the personal computer. 

Preferably, the first transceiver includes one of a subscriber transceiver in a subscnber 
prenuses,andaconcentrator. and the electric power line isapartofamains voltage power to^ 

5 network to which the subscriber transceiver and the concentrator are connected. 

There is additionally provided, in accordance with a preferred embodiment of Ihe 
present invention, communication apparatus, including: 

a subscriber transceiver, for deployment in a subscriber premises, the subscriber 
transceiver being adapted to be coi^led to an electric power line belonging to a mains voltage 

1 0 power line network; and 

a concentrator, coupled to the power line network so as to convey data between the 
subscriber transceiver and a packet communication trunk, the subscriber transceiver and ±c 
concentrator being configured to estabUsh a data link therebetween over the electnc power 
line such that upon receiving a sequence of data packets for transmission over the data hnk, 

15 the sequence belonging to a session of a comiectionless real-time networic protocol, the 
subscriber transceiver and the concentrator are adapted, responsive to a first packet m the 
sequence, to estabUsh a reUable connection channel for the session over the data link and to 
transndtthepackets in the sequence from one to another over the reliable comiectionchamxel. 
The present invention will be more fiilly understood fiom the foUowing detailed 

20 descriptionofthepreferrcdembodimentsthereofttakentogptherwiththedmwings^ 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram &at schematically illustrates a system for power line 
communications (PLC), in accordance with a preferred embodiment of the present mvention; 
Fig. 2 is a block diagram that schematicaUy shows details of a power line data 
25 transceiver, in accordance with a preferred embodiment of the present mvention; 

Fig. 3 is a block diagram that schematically shows communication protocols used to 
carry voice traffic in a PLC system, in accordance with a preferred embodiment of the present 
invention; 

Fig. 4 is a table that schematically illustrates a packet header used in real-time network 

30 communications; 

Fig. 5 is a flow chart that schematically illustrates a method for compressing packet 
headers in a PLC system, in accordance with a prefenred embodiment of the present invention; 
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Fig. 6 is a flow chart fliat schematically illustrates a method for decompressing 
compressed packet headers, in accordance with a preferred anbodiment of the present 
invention; 

Figs. 7A-7D are tables that schematically illustrate packets headers used in the header 
5 conqnession and decompression methods of Figs. 5 and 6; and 

Fig. 8 is a flow chart that schematically iUustrates details of a method for packet header 
conq)ression. in accordance with a preferred embodiment of the present invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
Fig. 1 is a block diagram lhat schematicaUy illustrates a communication system 20, in 
10 accordancewithaprefenedembodimentoflhepresentinvention. System 20 is built around a 
power line communication (PLQ network 22, which uses a power line 24 to cany digital 
packet communications to and from a plurality of subscriber premises 26, 28, .... Power line 
24 preferably comprises a network of power lines supplying mains voltage, typically at a level 
of 1 20 VAC or 240 VAC, which share a common step-down transformer 30, connecting power 
15 line 24 to the medium/high-voltage power grid. It wiU be predated, however, that the scope 
of the present invention is not limited to a specific level or type of line voltage. 

Premises 26, 28, ..„ typically comprise homes and/or offices and/or other receiving 
units of the electric power. Each premises is served by a transceiver 34, which acts as an 
interfece between power line 24 and subscriber equipment, such as a personal con5)uter 36 and 
a telephone 38. Transceiver 34 is described in greater detail below wilh reference to Fig. 2. 
One or more master transceivers, referred to herein as a concentrator 3 2, couples power line 24 
toapacketnetworictrunk40. The trunk typically has the form of a wide area networic (WAN) 
maintained by an electric utility company to carry commmiications between the concentrators 
on different low-voltage segments of the power system, such as on line 24. 

Trmk 40 is typically coupled to a variety of different pubHc communication networics, 
including the Internet and a public switched telephone network (PSTN) 44. This connection 
enables subscribers in premises 26. 28. to place and receive telephone calls over PLC 
networic 22. Preferably, the calls are carried between transceivers 34 and a telephony gateway 
42 in the form of packetized voice and signaling data, typically using Internet Protocol (IP) 
communications on both power line 24 and trunk 40. Gateway 42 interfaces with PSTN 44, 
converting IP packets to PSTN audio and signaling, and vice versa, as is known in the art.' 
Signaling for calls on PLC network 22 is routed to a gatekeeper 46. which is a server 
responsible for tasks such as assigning an IP address to the calling party, verifying that the 

7 



20 



/Q 02/25822 



Page lOof 37 



PCT/ILOl/00872 

WO 02/25822 

caUed party is available and that flxe call is aufliorized, and monitoring calls for billing 
purposes. A network management system (not shown) coupled to trunk 40 is responsible for 
allocating bandwidth to calls, depending on the load on PLC network 22. Preferably, the 
level of compression of the audio data carried on network 22 and tnmk 40 is variable, under 
5 controlofthenetworkmanagemeritso^intesponsetovariatio^ 

As an addition or alternative to gateway 42, telephone calls to and from transcdvers 34 
m^ be handled through a virtual private branch exchange (PBX) 48. coupled to trunk 40. 
PBX 48 is preferably implemented as a special telephony ^pUcation running on a 
general-purpose network server. In addition to interfecing with PSTN 44, PBX 48 acts as a 
10 switch in a private telephone network serving customers of the electrical utiUty company who 
use PLC network 22 for flieir telephone calls. PBX 48 routes local telephone calls between 
such customers through trunk 40 and the subscribers' local power lines 24. without using 
PSTN 44. This feature of the PBX allows flie utiUty company to oflfer local tele|»hone service 
at reduced rates, relative to the PSTN. Outgoing and incoming calls involving telephone 
15 subscribers outside the local PLC network are routed by PBX 48 to and from PSTN 44, in a 
manner similar to VoIP gateway 42. 

Voice telephony is thus carried over PLC networic 22 in much the same way as oflier 
types of packet data, but with a few important differences. One difference is that the telephony 
packets are preferably assigned a high level of priority, relative to other types of traffic, so as 
20 to provide adequate quality of service (QoS) for real-time voice. In addition, the voice packet 
headers are conq)ressed to conserve bandwidth on flie PLC network, as described in detail 
hereiiibelow. Other real-time multimedia traffic, such as real-time video, which is typically 
fed to PLC networic 22 from the Internet and &om entertainment networics, is preferably 
treated in a similar fashion to voice, with high priority and header compression. Therefore, 
25 aKhou^ preferred embodiments are described herein primarily with reference to telephony 
appUcations, it will be understood that the principles of the present invention are similarly 
appUasblo to other types of real-time data traffic. 

Fig. 2 is a block diagram that schematically shows details of one of subscriber premises 
transceivers 34, in accordance with a preferred embodiment of the present mvention. The 
30 design and operation of transceiver 34 are described in greater detdl in PCT Patent 
AppUcation PCT/ILOl/00745, filed August 12. 2001, which is assigned to the assignee of the 
present patent appUcation and whose disclosure is incorporated herein by reference. 
Transceiver 34 comprises a multi-fimction modem unit 50. which acts as an interfece between 
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power line 24 and low-voltage data infonnation lines. Modules of unit 50 act as 
data-conversion ciicuitiy, accepting incoming data fiom elements such as a network or a 
telephone and converting the data to dgnals conq>atible with the power line, as weU as 
performing the reverse operation. Certain modules also act as a data communication controUer 
52, and as level-setting circuitry for transmission of the data. 

Transceiver 34 is preferably coupled to line 24 by an industry-standaid power socket 
56. A physical interfece (PHY) module 54 acts as a full-duplex converter between serial data 
signals of a data link unit 58 and power line signals of power line 24. A logic module 60 
communicates with a central processing miit (CPU) module 62. which is used to operate and 
control other modules comprised in the transceiver. In addition to acting as an overuU 
controUer for transceiver 34, CPU 62 is utilized to convert data received by and transmitted to 
oflier modules of the transceiver, as well as to control routing of communications between 
transceiver 34 and other elements of PLC network 22. CPU 62 preferably operates using a 
volalile memory 66 such as a random access memory (RAM), containing a routing table 68. 
and a non-volatile memory 70, such as a flash memory. Memories 66 and 70 are coupled to 
CPU 62 by an internal bus line 64. 

CPU 62 communicates with the other modules of transceiver 32 via logic module 60. 
which acts as a multiplexer, transferring data to and fiom subscriber equipment interfeci 
modules 72, 78, 80, 82 and 86, whose functions are des^bed below; 

• CODEC module 82, preferably an industry-standard CODEQ transmits and 
receives standard telephone signals via an industry-standard connector 84 to and fiom 
telephone 38. The CODEC converts the analog telephone signals to a suitable digital 
form, such as the H.323 format promulgated by the International Telecommunications 
Union (ETU), and vice versa, in a fuU-duplex manner. 

• ECP module 80 communicates with personal computer 36 via an industry-standard 
parallel port of flie computer. 

• RS-232 module 86 provides industry-standard serial communication, via a 
connector 128. 

• Ethernet module 72 provides packet data communications, using a standard 
protocol such as lOBaseT, via a comrector 74. Computer 36 may comiect to module 
72 either directly via cormector 74 or via a LAN 76. 
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. Alternatively or additionally. Universal Serial Bus (USB) module 78. which is 
preferably coiq»led directly to Ca»U 62. commumcates with a USB host via connector 
74. 

Fig. 3 is a block diagram that schematically illustrates protocols used in voice 
communications over PLC network 22, in accordance with a preferred embodiment of ihe^ 
present invaition. The communications are shown, by way of example, as taking place 
between either personal computer 36 or telephone 38 and Voff gateway 42. via subscriber 
PLC transceiver 34 and concentrator 32. The communications are generated at the subscriber 
end as a RTP packet stream, which is prefisrably produced by a suitable IP telephony 
^Ucation running on computer 36. Alternatively, the subscriber may use telephone 38 to 
generate audio and signaling, hi this case, CODEC module 82 converts the telephone oulput 
to standard digital form, and data link unit 58 generates the RTP header data, as weU as 
processing the RTP packets returned fiom the party at the other end of the tel^hone call. 

Thus, a subscriber-end protocol stack 100 shown in Fig. 3 comprises RTP, UDP and IP 
layers on Ihe subscriber side, running over local media access control (MAC) and physical 
layer communications provide by the ^propriate subscriber equipment interfaces, such as 
Ethernet interfece module 72. When CPU 62 generates or detects an outgoing RTP/UDP/IP 
packet stream, it preferably estabUshes a point-to-point connection between transcdver 34 and 
concentrator 32 for the purpose of carrymg the stream, and then compresses flie padcet headers 
in the RTPAJDP/IP session, as described in detail hereinbelow. Concentrator 32 preferably 
functions in like manner wilh respect to incoming packet streams from trunk 40. The RTP. 
UDP and IP layers are then carried on power line 24 between subscriber transceiver 34 and 
concentrator 32 by a special, compressed telephony layer, over the PLC MAC and physical 
layers generated by data link unit 58 and PHY module 54. The MAC layer protocol is 
described in detail in the above-mentioned PCT patent appHcation. 

In a concentrator stack 102. running on concentrator 32, the compressed tel^hony 
layer for outgoing calls is deconq)ressed to recover the original RTP, UDP and IP headers. 
Conversely, iricoming RTP/UDP/IP headers are compressed for transmission to transceiver 34, 
The RTP/UDP/IP voice packets may also be carried over packet trunk 40 in compressed form, 
and decon^essed at gateway 42 or at another point along the way. The MAC and PHY layers 
on the trunk side of concentrator 32 are typically those of a standard data linkprolocol used on 
the packet network to v^ch trunk 40 belongs, preferably an Ethernet protocol. 
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A VoIP gateway stack 104 is used by gateway 42 to interface with PSTN 44. Hie 
gateway stack is preferably built on protocols known in the VoIP art. including H323. along 
with the Session Initiation Protocol (SIP) for call signaling and the Media Gateway Control 
Protocol (MGCP) for handling audio data flow. 
5 Fig. 4 is a table that schematically illustrates fields in the RTP/UDP/IP/Bthemet header 

structure, which are used in the compression scheme described below. As indicated by a 
legend at flie bottom of the figure, the fields are coded to show which typically change in the 
course of a RTP session, and which do not. Some of the fields are shown as being optional or 
"expendable," indicating that Ihey can be deleted at one end of the session comiection and 
10 recovered if necessary at the other end. Further information regarding the header fields is 
provided in the above-mentioned RFC 1889 and RFC 2508. 

In a RTP header 1 10, the version and SSRC numbers should remain constant for the 
duration of a session. The P, X, CC, M and PT fields in the header change occasionally at 
most, as does the contributing source identifier (CSRQ. The packet sequence number and 
15 time stamp fields change fiom one packet to the next, typically by a constant increment. The 
expected increment of the pad«t sequence number is 1, while that of the time stamp depends 
on the CODEC being used. (For example, for G.729. the typical time stamp increment is 160.) 

In a UDP header 112, the UDP source port and destination port do not usuaUy change 
in the course of a session, althou^ they may occasionally do so. By convention, 
even-mmibered UDP ports are used for RTP traffic. The UDP segment length is generally 
redundant, since it can be recovered from packet parameter, of lower-layer protocols 
Although UDP packets conventionalfy cany a checksum, this field can also be omitted in some 
or all of the packets. 

In an IP header 114. most of the fields also change rarely if at afl in ttte course of a RTP 
session. As in the case of the UDP length, the IP total length can be deleted and recovered 
subsequently fiom lower-layer protocol information. The IP packet identification (ED) is 
normally incremented by one for each new packet. 

FinaUy, in an Ethernet header 1 16. the source and destination information, identifying 
the transceivers at the ends of the link, must remam constant dming any given session. 

B ased on the information in Fig. 4, it is evident that any given RTP session between a 
subscriber premises transceiver 34 and concentmtor 32 can be represented by context 
information that changes little if at all in the course of a session. As sessions are created, each 
session is assigned a unique context ID (QD), or chamiel number. lUe session context is 
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Stored in a pool in memory by both the transceiver aad the concentrator (for example, in 
memory 66, Fig. 2). The context entries are preferably stored in the memory as a linked Ust, 
referenced by a hashing function based on a certain number of the least significant bits (LSB) 
of the RTF SSRC and the ff destination address for the respective sessions. Table I below 
shows a piefraied structure for the memory pool context entries. 

TABLE I - SESSION CONTEXT PARAMETERS 



Category 


Field 


Size 
(bits) 


CID 


Context ID (chaimel number) 


8 


Counters 


Number of CONTEXT_STATE (ACK or NACK) 
packets received (see description below) 


8 




Total RTP packets received 


16 


Seq 


Sequential number of conq>res8ed packet 


4 


State 


Channel state (active, inactive, pending - see below) 


4 




Last vpdate to this channel - channel is deared after 
timeout occurs with no update 


32 




Pbit 


1 




Xbit 


1 




CC 


4 




Mbit 


1 




Payload type 


7 




Previous sequence niimber 


16 




Previous timestamp 


32 




SSRC 


32 




CSRC (pointer to list) 


16 


UDP 


Source port 


16 




Destination port 


16 


IP 


IHL 


4 




Type of service 


8 




Previous ID 


16 




Flags 


3 
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Fragments 


13 




Time to live 


8 




Source address 


32 




Destination address 


32 




Options + padding 


32 


iitaeinet 


Source MAC address 


48 




Dcstmauon Mau address 


48 


ACKs 


Last seq nuniber acknowledged 


4 




Last CRC scat (on seq number) 


16 


D 


Debug state 


1 


Next_entry 


link to next entiy or end of list 


15 



10 



Fig. 5 is a flow chart that schematically iUustrates a method for processing an outgoing 
packet stream at transceiver 34. for the purpose of RTP header compression, in accordance 
with a preferred embodiment of the present invention. For the sake of clarity, the process is 
described fiom the perspective of the subscriber-side transceiver. It ^ be understood 
however, that a similar process is typically appKed to incoming packet streams by concentrato^ 
32. Each packet coming into transceiver 34 from the subscriber equq>ment is processed by 
datalinkunit58.atapacketpieparationstepl20. The data link mat examines each packet at 
a packet examination step 122. to determine whether it is a RTP/UDP/IP packet, making it a 
candidate for RTP headercompression. Non-RTP packets are seat to concer^r 32 without 
header compression, at a packet sending step 124. 

When unit 58 determines that it has received a candidate packet for header 
compression, it checks tte RTP SSRC and IP destination fields in the packet header against its 
memory pool (using the above^entioned hashing function) to detemnne whether the packet 
to a session, or chamiel. that has already been opened, at a context checking stq, 126 
If such a session is not found, unit 58 next checks to determine whether it has sufficient 

memory resources available to open a new session, at a channel availabiUty step 128. Ifthere 
IS no chamiel avaUable. the packet is sent without compression, at step 1 24. Similarly, unit 58 
should also check whether the RTP version is the con^t one, and whether the RTP payioad 
type is known. If the P bit is set in the RTP header, the last octet of the packet must contain a 
vahd octet comit Cess than the total packet length minus the header size). If any of these 
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conditions are not satisfied, a channel should not be opened, and the padcet should instead- be 
sent without compression at step 124. 

When a new channel is available, data link unit 58 creates the channel in its memory 
pool, and assigns it a context ID (CID), at a channel creation step 130. The memory pool now 
includes the full packet context, as specified in Table I above. To notify concentrator 32 that a 
new channd has been opened, unit 58 replaces the UDP length field in the UDP header (Fig, 
4) with a FULLHBADER identifier field, at a header replacement step 132. The 
FULLHEADER identifier, shown below in Fig. 7A, includes the assigned CID and the 
starting link sequence number (Seq). The modified packet is then sent on to concenHator 32. 
at a new packet transmission step 134. Upon reading the packet header with the 
FULL_HEADER identifier, the concentrator opens the channel in its own memory pool, using 
the CID, Seq and context information in the packet header, and is now ready to receive 



When at step 126, data link unit 58 determines that the current RTP packet belongs to 
an existing session already opened in the memory pool, it Tq)dates the corresponding chamiel 
timejag field, at a timCT update step 136. B then checks the channel state (see Table I) to 
detemiine whether or not the channel is active, at an activity checking st^ 138. A chaimel is 
deemed inactive when the concentrator has signaled, using the acknowledgment mechimism 
described below, that it has received packets with errors or that packets have been lost on this 
channel. In such as case, the original packet is sent without header compression to 
concentrator 124. A channel may be deemed pending i^ upon an attenq)t by data link unit 58 
to create the channel, concentrator 32 responds that its memory pool is fliU. Packets are 
likewise sent over pendiiig channels without header compression. Such channels are 
ultimately erased &om the memory pool of data link unit 58 by an aging mechanism if 
resources are not fireed so that the pending channels can become active. 

When the RTP packet is found at step 138 to belong to an active channel, data Unk unit 
58 performs vaUdity checks to ascertain fliat the channel is still vaUd, at a validity checking 
step 140. The packet header is then conqoessed, and the compressed packet is sent to 
concentrator 32, at a compressed transmission step 142. Details of steps 140 and 142 are 
described below wifii reference to Fig. 8. 

Fig. 6 is a flow chart that schematically illustrates processing of conq)ressed packets 
received by concentrator 32 ftom transceiver 34, in accordance with a preferred embodiment 
of the present invention. (As in the case of the method of Fig. 5, this same method is carried 
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out by data link mrit 58 of transceiver 34 when it receives packets from the concentmtor ) 
Upon anival of each packet from transceiver 34, at a packet arrival step 150, concentrator 32 
checks the packet header. By examining the packet header fields, the concentrator is able to 
determine whether the packet belongs to a known RTP header conq«ession type, at a 
5 suppression determination step 152. If not. the concentrator singly sends the packet on to TP 
trunk 40 without changes, at a packet pass-on step 154, accept for the necessary changes to 
Bthemet header 116 (Fig. 4) that are mandated by standard protocols. 

When concentrator 32 detects a RTP packet with a suppressed header type, it nert 
checks the context ID (CID) in the packet header to determine whether this chamiel already 
10 -.sts in its memory pool, at a channel checking step 156. lie memory pool of the 
concentrator (at the receiving end of the KTP session) is nearfy the same as that shown above 
for the sending end in Table! One difference is that the memory pool at the receiving end 
contains the MAC address of the packet source (transceiver 34) on PLC network 22. Another 
-^-tthe'Wers^categorycontainscountsofthenumberofacWl^^^^ 
15 and the number of RTP packets received on the chamieL Furthennor.. channels at the 
leceivmg end of the connection can have only two states: active and inactive. 

If the cm of the packet does not exist in the memory pool at concentrator 32. the 
concentrator checks the packet to verify that it is a FULL_HEADER type, at a header checking 
step 158. As noted above, this is the packet type that transceiver 34 sends to initiate opening 
«) °f«»«^ol--eI.IfthisisnottheexpectedFULL_HEADBRtjpeofpacket.con^ 

sends a CONTBXT.STATE packet back to transceiv^ 34. indicating that it was unable to 
forward the packet, at a context r^ply step 162. (The CONTEXT_STATB format, shown in 
Fi& 7D. is used by the recipient of compressed packets to signal acknowledgment- ACK- or 
-^«veacknowledgment-NACK-ofthepackets.asdescribedbelow.)TW^ 
> anse, for example, when the transceiver reboots itself in the middle of the transmission 

sequence, or when the first FUIX_HEADER packet is lost in ti^t to the concentrator m 

suchcases.thetransceiverandconcentratormustresynchronizebeforethey^ 
communications. 

<*ecb, to deta=>tac I. a new cWd to it, „«,„„.y pool, a, an «==,y 

ctaond checking Step 160. Iftoon,»y„f fl.,tan«ei,„,taaubscriberprenusee26 28 
^^n^ .elepbon. call, „™ Pix; nrtwo* 22. fte conc«^ n«y ten^orrtly' Z 
out of channels. L, to ca«. too. tt, concBitrator «^ a CONTEXT.STAIB packet back to 
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transceiver 34. indicating that it is out of free channels, at a reply step 162. Despite the 
negative response, however, the concentrator is still able to reconstruct the original, standard 
RTP/UDP/IP header by recalculating tiie UDP length, at a length recalculation step 164. and 
rdnserting the length into the UDP header of the packet in place of the FULL.HEADER field 
5 that was substituted by transceiver 34. TTie concentrator then sends the reconstructed packet 

out over IP trunk 40. 

Returning to step 156. if concentrator 32 finds that the CID in the packet header exists 
in its own memory pool, it updates the time_tag in the corresponding channel context, at a 
timer updating step 170. It checks the source MAC address of the packet against the context. 

10 to ensure ttat the packet is valid, at a vaUdity checking step 172. It also checks the sequence 
number (Seq) of the packet to ensure that it is exactly one greater flian the precedmg packet 
received on this channeL If so. concentrator 32 can proceed to decompress the packet and 
reconstruct the RTP/UDP/IP header, at a decompression step 174. Details of the 
decompression process are described hereinbdow. If a packet is missed, the chamiel becomes 

1 5 inactive, and the packet cannot be deconqncessed or sent 

In order to maintain synchronization between the sender and receiver of conqoessed 
packets, the receiver is requited to acfcaowledge the compressed packets it has received, at an 
ACK requirement step 176. For this purpose, a time window. T. is defined at both the sending 
and receiving ends, such that every T compressed packets an acknowledgment protocol is 

20 carried out The sender preferably saves the sequence number and spends a cycUo 
redundancy code (CRC) value to the packet whose acknowledgment is required. The receiver 
reconq)utes the CRC and compares it to the appended value. If the CRC values match, the 
receiver returns an ACK packet (i.e.. a CONTEXT.STATE packet) with the sequence number 
to the sender, at an acknowledgment step 178. If there is a mismatch of the CRC values, the 

25 receiver returns a CONTEXT.STATE NACK packet. In an optional debuggmg mode, the 
receiver may check the CRC of every packet, and send a NACK response to the sender for any 
packet in which the CRC check fails. When the sender receives the ACK response from the 
receiver, it checks the sequoice number and CRC value against the values it has saved, and 
clears the values if they match. If the sender does not receive the proper ACK. it sends a 

30 PXJLLJEIEADER packet in order to refi«sh the channel context 

When concentrator 32 determines at step 172 that a packet has been lost, it must send a 
NACK to transceiver 34. in the form of a CONTEXT_STATB packet Hie NACK packet 
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reports the sequence number of the last packet received and requests tiansmission of a 
FULLJEDBADBR packet to update the channel context. 

Figs. 7A.7D are tables that schematically illustrates the types of packets sent between 
transceiver 34 and concentrator 32 in carrying out the compression and decompression 
5 protocols of Figs. 5 and 6. Tlie packet types generally foUow flie definitions in the 
abov^mentioned RFC 2508. with changes q,propriat« to the specific constraints and 
requirements of PLC network 22. Fig. 7A shows a FULL_HEADER field 200 that is inserted 
in place of the length field in the UDP header (Fig. 4) of a fuU RTP/UDP/IP packet header. 
Field 200 includes a version nmnber 202 (for example. "0V% context ID (OD) 204. and a 
10 current sequence number (Seq) 206. An optional ♦«D» bit invokes the above-mentioned debug 
mode, in which a CRC is added by the sender to each of the compressed packets and is 
chedced by the receive. 

Fig. 7B shows a COMPRESSED_UDP packet 210. which is sent by the transmitter 
when the P. X or PT field in the RTP header has changed. When such a change occurs, 
additional information must be conveyed to the receiver in order to update the chamiel context, 
and this mfotmation is conveyed by the COMPRBSSBD_UDP packet. Hie packet headed 
includes OD 204 and Seq 206, as weU as an *T' flag 212. This flag is set if the IP version 4 
(n>v4) ID has changed by an amount other than one fi-om the preceding packet to this one. If 
'T' is set, packet 210 includes a AIP field 214 that gives the actual ID change. Preferably, flie 
change in ID is encoded using a HufBnan encoding scheme, as is known in the art, so that 
common values of the ID change (typicaUy in the range 0:127) are encoded as a single byte, 
while less common values take two or three bytes. A scheme of this sort is suggested in RFC 
2508. No further encoding of the IP or UDP header is required. (H it were, a 
FULL.HEADER packet would be sent.) The packet next includes UDP data 216, which 
comprises the fuU RTP header and payload, followed by an optional checksum 218. 

Fig. 7C shows a COMPRESSED_RTP packet 220. which is sent when the changes in 
the RTP/UDP/IP header are minimal. FoUowing OD 204. the packet includes compression 
flags 222. wifli the following meanings: 

• "M» indicates that the 'M" bit in the RTP header has changed. 
. "S» indicates that the RTP sequence number has changed by an amount different 
&om the usual sequence mcrement. In this case, a ARTP sequence field 224 contains 
the actual change in the sequence number, preferably using a Huffinan encoding 
sdieme as described above. 
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• «T' indicates the RTP timestamp has changed by an amount different fiom the 
usual time increment In this case, a ARTP timestamp field 226 contains the actual 
change in the timestamp, preferably using a HufBnan encoding scheme as described 
above. 

5 - . 'T' indicates that the IPv4 ID has changpd by an amount different Scorn one, with its 

actual change given by field 214. 

• When all of M, S, T and I are set, and a CXJ field 223 is not equal to zero, a CSRC 
list 228 is included in packet 220, wilh a length given by the value of CC. In this case, 
the values M-S^T^I-l ate artificial, to signd that flie packet includes tiie CSRC list, 

10 and the roles of flags M, S, T and I are respectively assumed by flags M', S', T' and F. 

If the "X" bit is set in the RTP headar, the header extension is contained in a RTP header 
extension field 230. The remainder of the packet contams RTP data 232, followed by optional 
padding 234 (if tiie "P" bit is set) and checksum 218. 

Fig. 7D shows a CONrEXT_STATE packet 240, used for the ACK and NACK 

15 functions described above. An "F* bit 242 is set by tiie receiver to indicate fliat its memory 
pool is full, so that a new channel fliat the tiansmitter has asked to open must remain in tiie 
pending state. An "A" bit 244 is set to indicate a positive acknowledgment (ACK), and is 
reset for NACK. Seq field 206 indicates flie sequence number of tiie last packet that tiie 
receiver was able to read on tiiis channel. The use of tiie CONTEXT_STATE packet in tills 

20 manner (vMch differs from tiiat proposed in RFC 2508), witii a predefined window for 
positive ACK response by tiie receiver, turns tiie unidirectional, connectionless RTP/UDP 
packet stream into a full-duplex, connection-oriented protocol witiiin PLC network 22, while 
at flie same time saving substantial bandwidtii. Botii of tiiese features are particularly 
important when working over power line 24, witii its high noise level and low bandwidtii. 

25 Fig, 8 is a flow chart tiiat schematically illustrates the use of packet formats 200, 210 

and 220 m sending compressed RTP packets over PLC network 22, in accordance witii a 
preferred embodiment of tiie present invention. The steps of tiie method shown in Fig. 8 
correspond roughly to validity checking step 140 and compressed transmission step 142 in Fig. 
5, after transceiver 34 has ascertained that tiie RTP packet in question belongs to an active 

30 channel in its memory pool. 

The mettiod of Fig. 8 is initiated when t:ansceiver 32 receives a RTP packet to 
compress on a vaUd, active channel, at a packet reception step 250. The transceiver first 
checks fields tiiat are supposed to remain constant over an entire RTP session: tiie IP source 
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address and Ibe UDP ports, at a constant field checking step 252. If any of these paiameteiB 
have changed in the cuirent packet, relative to the channel context in the memoiy pool, the 

cunentchannelis erased, at an erasure step 254. A new channel be created in its place 
with the new parameters. 

5 Next, the ttanscdver checks whether any of the other IP paiametCTC have chm 

an IP checkmg step 256. These fields arc also generally constant during a session, with the 
exception of the IP ID field, which is incremented fiom packet to packet If any of the 
parameters have changed, other than the IP ID mcr«nent, the transceiver sends a 
FULLHEADER packet, at a flill transmission step 258. This packet refieshes the contents of 
10 the channel context, but without creating a new channel. 

If the packet passes step 256 successfiilly. the transceiver checks to determine whether 
any of the P. X or PT fields of the RTP header have changed relative to the channel context, at 
a RTP parameters diecking step 260. As noted above, if any of these fields have changed, 
compressed UDP packet 220 is sent, at a cor^r^ssed UDP sending step 262. If the IP ID 
increment has changed, the packet wiU also include the q)prDpriate AlPv4 ID field 214. 

If none of these RTP fields have changed, the transceiver checks the other RTP header 
fields, as weU as the IP ID field, m order to encode any changes in the fields, at an RTP 
encoding step 264. These changes include changes in the fields themselves, for the M and 
CSRC fields, as weU as changes in the increment of the sequence number, timestamp and IP 
ID fields. Any changes are encoded in the manner described above, and the corresponding 
flags 222 and .CC field 223 are set accordingly, at a flag raising step 266. Most of the time, 
fields 214, 224. 226 and 228 are empty, so that flags 222 and field 223 are zero. Tlie packet 
can now be sent to the concentrator 32. 

In order to monitor decompression processing activities, concentrator 32 preferably 
5 maintains fbe following counters: 
• Global counters - 

• Total RTP packets reconstructed. 

• Total synchronizing (FULL_HEADER) packets received. 

• Total semi-con^aessed packets received (COMPKESSED_UDP). 

• Total fiiUy-compressed packets received (COMPKESSED_RTP). 

• Total synchronizing packets sent (CONTEXT_STATB with F bit ofi). 

• Total reject packets sent (CONTEXT_STATE with F bit on). 

• Total active channels. 
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• Total inactive channels. 

• Number of available channels. 
• Per-channel counters — 

• Total com^iessed packets received. 

5 • Total synchronizing packets sent (CONrBXT_STATE with F bit off). 

Reconstruction of the compressed packets, at deconqwession step 174 (Fig. 6) is a 
minor image process to that shown m Fig. 8. When the compressed packet is a 
COMPRESSBD_UDP padcet, concentrator 32 geaerates the decompressed RTP packet to 
send over trunk 40 usmg the RTP channel infiomation in UDP data 216, along with the 

10 remaining context data for the channel that is stored in the memory pooL Ihe concentrator 
mcrements the IP ID by 1 if 1=0. or by the number indicated in field 214 of the packet if 1=1 . 

For a COMPRESSEDJRTP packet, if ^1=8=1^1=1, and CC is non-zero, the CC field 
in the channel context is updated with the value in field 223 of packet 220, and the CSRC list 
in the context is replaced with the contents of field 228 in the packet. This new infonnation is 

15 used in all reconstructed packets, beginning with the current one. Depending on the values of 
M, S. T and I (or of M', S'. T' and 1% if M=S=T=I=1), the remaining variable fields of the 
RTF packet are reconstructed, using constant increments or the special mcrements given in 
fields 214, 224 and 226. Header extension 230 and padding 234 are optionally added to the 
packet, the UDP length is recalculated, and the packet is sent out on trunk 40 as a standard 

20 RTP/UDP/IP packet 

As noted above, althou^ the processes of channel creation and of compression and 
decompression of RTP packets are described with respect to packets transmitted from 
subscriber equipment, via transceiver 34, to concentrator 32 over power line 24. similar 
methods are used to create channels and to compress and decompress packets received by 

25 concentrator 32 firan packet trunk 40 for transmission over the power line to transceiver 34. 
Furtheraiore, although for the sake of clarity, these processes are illustrated with reference to a 
smgle connection in the very simple PLC network 22 shown in Fig. 1, it will be understood 
that flie methods exemplified by the preferred embodiments described herein may equally be 
appUed in more complex PLC network topologies, with multiple RTP sessions going on 

30 simultaneously. 

More generally speaking, while RTP/UDP/IP provides particularly fertUe ground for 
creating connection-oriented sessions and performing header compression in a PLC networic. 
the principles of the present mvention may also be appUed to other connectionless protocols, 
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particularly real-time protocols, that are used in the PLC network environment FurthemioiB, 
although preferred embodiments are described herein witii specific reference to PLC netwoiicB, 
the principles of the present invention may also be appHed, mutatis mutandis, to enciq)sulation 
and compression of packets transmitted over wireline and wireless networks of other types, 
particularly networks that, like PLC networks, have high noise and error rates. 

It will thus be appreciated that the preferred embodiments described above are cited by 
way of example, and that the present mvention is not limited to what has been particularly 
shown and described hereinabove. Rather, the scope of the present invention includes both 
combinations and subcombmations of the various features described hereinabove, as well as 
variations and modifications thereof which would occur to persons skiUed in the art upon 
reading the foregoing description and which are not disclosed in the prior art 
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CLAIMS 



1. A method for communication, comprising: 

estabUshing a data link between first and second transceivers over an electric power 

line; 

5 receiving a sequence of data packets for transmission over the data link, the sequence 

belonging to a session of a connectionless real-time networic protocol; 

responsive to a first packet in the sequence, estabUshing a reUable connection channel 
for the session over the data link between the first and second transceivers; and 

transmitting the packets in tibe sequence from the first to the second transceiver over 
10 the reliable coimection channel. 

2. A method accordmg to claim 1. wherein the packets comprise header information, and 
wherein transmitting the packets comprises compressing the header information in the packets 
transmitted using the channel fi»m the first to the second transceiver. 

3. A method according to claim 2, wherein estiiblishing the reliable connection channel 
15 comprises storing context information wifli respect to ttie session at the first and second 

transceivers, and wherein compressing the header information conq>rises compressing the 
header information using the stored context information. 

4. A method according to claim 3, wherein storing the context information comprises 
conveying Ihe context information to the second transceiver along with a channel identifier in 

20 the first packet in the sequence, and wherein compressing the header information comprises 
inserting the channel identifier in the packets in the sequence foUowing the first packet as a 
reference to Ihe context information. 

5. A method accordmg to claim 4, and comprising reconstructing the compressed header 
inforaiation at the second transceiver using the stored context information referenced by the 

25 channel idratifier. 

6. A method according to claim 2, wherein compressing the header information comprises 
detecting changes in the header information in successive packets in the sequence, and 
encoding fiie changes. 

7. A method according to claim 1, and comprising sending an acknowledgment firom the 
30 second transceiver to the first transceiver responsive to at least some of the packets in the 
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sequence transmitted by the first transceiver, thereby maintaining the rehable connection 
chazmeL 

8. A method according to claim 7, wherein estabhshing the reliable connection channel 
comprises determining an acknowledgment interval that con^rises a given nmnber of the 
packets, and wherein sending the acknowledgment conqirises sending the admowledgment 
every time the given number of packets has been received at the second transceiver. 

9. A method according to claim 8, wherein transmitting the packets comprises adding an 
error detection code at the first transceiver to one of the packets in the ackaowledgment 
interval, and wherein sending the acknowledgment comprises checking the error detection 
code at tiie second transceiver, and indicating a result of tiie checking in the acknowledgment 

1 0. A method according to claim 7, wherein transmitting the packets comprises adding a 
channel sequence number to each of tiie packets, and wherein sending tiie acknowledgment 
comprises sending an mdication fiom tiie second transceiva- to tiie first transceiver when flie 
channel sequence number of tiie packets received at tiie second transceiver deviates fiom a 

15 consecutive order. 

11. A mettiod according to claim 7, wherein estabUshing ttie rehable connection channel 
comprises sending a request fiom tiie first transceiver to tiie second transceiver to allocate a 
resource for tiie channel, and wherein sending tiie acknowledgment comprises indicating to tiie 
first transceiver whetiier or not tiie second transceiver has tiie resource available to open tiie 

20 channel. 

12. A metiiod according to any of claims 1-11, wherein tiie first and second transceivers 
comprise a subscriber transceiver in a subscriber premises and a concentrator, and wherein tiie 
electric power line is a part of a mains voltage power line networic to which tiie subscriber 
transceiver and tiie concentrator are connected. 

5 13. A metiiod according to claim 12, wherein tiie subscriber transceiver is one of a pluraUty 
of such tiansceivers in multiple, respective subscriber premises comiected to tiie power line 
network, and wherein flie concenhrator is coupled to link tiie pluiahty of tiie transceivers to a 
packet communication trunk. 

14. A metiiod according to claim 13. wherein receiving tiie sequence of flw data packets 
comprises receiving a real-time data flow to be conveyed between tiie subscriber premises and 
a networic server via tiie packet communication trunk. 
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15. A method according to claim 14. wherein receiving the real-time data flow comprises 
receiving telephony data, and wherein the network server comprises a telephony gateway, 
which is coupled to a public switched telephone network (PSTN). 

16. A method according to claim 15, wherein receiving the telephoiQr data conqnises 
5 receiving data associated with a telephone call placed fcom one of tiie multiple subscriber 

premises connected to the power line network to another of the multiple subscriber premises, 
and wherein the telephony gateway is fiirthBr configured to serve as a virtual exchange, so as to 
convey the telephony data ftom flie one of the subscriber premises to the other without sending 
the data through the PSTN. 
10 17. A method according to any of claims 1-1 1, wherein receiving the sequence of the data 
packets comiaises receiving real-time multimedia data. 

18. A method according to claim 17, v/hccciin receiving the multimedia data courses 
receiving video data. 

19. A method according to claim 17, wherein receiving the multimedia data comprises 
15 receiving voice data, 

20. A method according to claim 19, wherein receiving the voice data comprises coupling 
a telq)hone handset to one of the transceivers, and conveying the voice data as an analog audio 
signal between the one of the transceiveirs and the telephone handset. 

21. A method according to claim 19, wherein receiving the voice data comprises coupling 
20 a personal computer to one of the transceivers, and conveying the data packets between the one 

of the transceivers and a voice q»plication on the personal computer. 

22. A method according to any of claims 1-11, wherein recdving the sequence of the data 
packets comprises receiving the packets in accordance with a Real-time Transfer Protocol 
(RTP). 

25 23. Communication ^aratus, comprising a first data transcdver, which is configured to 
establish a data lirdc with a second data transceiver over an electric power line, such that upon 
receiving a sequence of data packets for transmission over the data link, the sequence 
belonging to a session of a connectionless real-time networic protocol, the first data transceiver 
is adapted, responsive to a first packet in the sequence, to establish a reliable connection 

30 channel for the session over the data link with the second transceiver and to transmit the 

packets in the sequence to the second transceiver over the reliable coimection channel. 
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24. Apparatus according to claim 23, wherein the packets comprise header infonnation, 
and wherein the first data transceiver is ad^ted to compress flie header infonnation in the 
packets for transmission using the channel. 

25. Apparatus according to claim 24, wherein to establish the reliable connection channel 
contejrt mformation with respect to the session is stored at the first and second transceivers, 
and wherein flie first data transceiver is ad^ted to con5)ress the header information using the 
stored context informatioa 

26. Apparatus according to claim 25, \^erein the first transceiver is adapted to convey the 
context information to the second transceiver along with a channel identifier in the first packet 
in the sequence, and to insert the channel identifier in the packets in the sequence foUowing 
the first pack^ as a reference to the context information. 

27. Apparatus according to claim 26, wherein the compressed header information is 
reconstracted at the second transceiver usmgihe stored context information referenced by the 
channel identifier. 

15 28. Apparatus according to claim 24, wherein the first transceiver is adapted to compress 
the header infonnation by detecting changes in the header mfonnation m successive packets m 
the sequence, and encoding the changes. 

29. Apparatus according to claim 23, herein the first transceiver is adapted, afta- 
estabUshing the reliable connection channel, to receive an acknowledgment fiom the second 

20 transceiver responsive to at least some of the packets in the sequence transmitted by the first 
transceiver, thereby maintaining the reliable connection channel. 

30. Apparatus according to claim 29, wherein the first transceiver is adapted to instract the 
second transceiver to send the acknowledgment every time a given number of packets makmg 
up a predetennined acknowledgment interval has been received at the second transceiver. 

25 31. Apparatus according to claim 30, wherein the first transceiver is adapted to add an 
em»r detection code to one of the packets in the acknowledgment interval, and to receive fiom 
the second transceiver in the acknowledgment a result of checking the enor detection code. 
32. Apparatus according to claim 29, wherein the first transceiver is adapted to add a 
channel sequence number to each of the packets, and to receive an mdication in the 
acknowledgment firom the second transceiver when the channel sequence number of the 
packets received at the second transceiver deviates firom a consecutive order. 

25 
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33. i^paratus accoiding to claim 29, wherein the first transceiver is ad^ted to send a 
request to &e second transceiver to aUocate aresomce for the leUable connection channel, and 
to receive the acknowledgment indicating whether or not the second transceiver has the 
resomce available to open the channel. 
5 34. Apparatus according to any of claims 23-33 wherein the sequence of the data packets 
coii5>rises real-time multimedia data 

35. Apparatus accordmg to claim 34, wherein the multimedia data con5)rise video data. 

36. Apparatus according to claim 34, wherein the multimedia data comprise voice data. 

37. Apparatus accoiding to claim 36, wherein the first transceiver conqaises a telephone 
10 adapter, which is configured to exchange the voice data m the form of analog audio signals to 

and from a telephone handset. 

38. Apparatus according to claim 36, wherein the first transceiver comprises a computer 
conununication port, which is configured to exchange the voice data in the form of voice 
packets to and fix>m a voice qiplication on the personal conq)uter. 

15 39. ^paratus according to any of claims 23-33, wherein the connectionless real-time 
protocol comprises a Real-time Transfer Protocol (RTP). 

40. Apparatus according to any of claims 23-33. wherein the first transceiver comprises 
one of a subscriber transceiver in a subscriber premises, and a concentrator, and wherein the 
electric power line is a part of a mains voltage power line network to which the subscriber 

20 transceiver and the concentrator are connected. 

41. Communication apparatus, comprising: 

a subscriber transceiver, for deployment in a subscriber premises, the subscriber 
transceiver being adapted to be coupled to an electric power line belongfaig to a mains voltage 
power line network; and 

25 a concentrator, coupled to the power line networic so as to convey data between the 

subscriber transceiver and a packet communication trunk, the subscriber transceiver and the 
concentrator being configured to estabUsh a data link therebetween over the electric power 
line, such that upon receiving a sequence of data packets for transmission over the data link, 
the sequence belonging to a session of a connectionless real-tune networic protocol, the 

30 subscriber transceiver and the concentrator are adapted, responsive to a first packet in the 
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sequence, to establish a reKable connection channel for the session over the data link and to 
transmit the packets in the sequence &om one to another over the reKable connection channel. 

42. i^paratus according to claim 41, wherein the sequence of the data packets conqwises a 
real-time data flow to be conveyed between the subscriber premises and a networic server via 

5 the packet communication trunk. 

43. Apparatus according to claim 42, wherein the real-time data flow comprises telephony 
data, and wherein the netwoik server comprises a telephony gateway, which is coupled to a 
public switched telephone netwoik (PSTN). 

44. Apparatus according to any of claims 41-43, wherein the subscriber transceiver is one 
) of a plurality of such transceivers in multiple, respective subscriber premises connected to the 

power line network, and wherein the concentrator is coupled to link all of the plurality of the 

transceivers to the packet communication trunk. 
• 

45. Apparatus according to claim 44, wherein the sequence of the data packets comprises 
telephoiQr data associated wifli a telephone call placed from one of the multiple subscriber 
premises connected to the power line networic to another of the mult5>le subscriber premises, 
and comprising a telephony gateway, coiqiled to the packet communication trunk, which is 
configured to serve as a virtual exchange, so as to convey the telephony data from the one of 
the subscriber premises to the otter wifcout sending the data through a pubUc switched 
telephone netwoik (PSTN). 

46. Apparatus according to claim 45, wherem when the telephony gateway is further 
coiq)led to the PSTN so as to convey telephone communications between the PSTN and the 
multiple subscriber premises. 
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